FHIR © HL7.org  |  Server Home  |  FHIR Server FHIR Server 3.4.11  |  FHIR Version n/a  User: [n/a]

Resource Requirements/FHIR Server from package hl7.ehrs.ehrsfmr21#current (47 ms)

Package hl7.ehrs.ehrsfmr21
Type Requirements
Id Id
FHIR Version R5
Source http://hl7.org/ehrs/https://build.fhir.org/ig/mvdzel/ehrsfm-fhir-r5/Requirements-EHRSFMR2.1-CPS.1.2.html
Url http://hl7.org/ehrs/Requirements/EHRSFMR2.1-CPS.1.2
Version 2.1.0
Status active
Date 2024-11-26T16:30:50+00:00
Name CPS_1_2_Manage_Patient_Demographics
Title CPS.1.2 Manage Patient Demographics (Function)
Experimental False
Realm uv
Authority hl7
Description Manage patient demographic information.
Purpose Demographic information (including names, addresses, phone numbers, email addresses, date of birth, gender, race, and ethnicity) must be managed to support unique patient identification, reporting, care provision requirements. Patient Demographic information may also include information about the patient's contacts, methods of contact (e.g., email or telephone), and modes of contact (e.g., call secretary during the day, send text message on the weekend). Patient demographic data are captured and maintained as discrete fields and may be enumerated, numeric, or codified according to scope of practice, organizational policy, and/or jurisdictional law. Key patient identifiers (i.e., name and primary patient record identifier) often appear on patient information output (e.g., rendering of a patient's record). Patients may have multiple, and/or compound names, sometimes employing accent marks or special characters. To help parse patient names, discete fields are often used. Example: For example, "Mary Jane Sue Smith" may be parsed as: First-name: “Mary Jane", Middle-name: ”Sue", Last-name: “Smith". Some jurisdictions may specify the capture and reporting of key patient demographic information (e.g., the "Meaningful Use, Stage 2" information requirements in the USA).

Resources that use this resource

No resources found


Resources that this resource uses

No resources found



Narrative

Note: links and images are rebased to the (stated) source

Statement N:

Manage patient demographic information.

Description I:

Demographic information (including names, addresses, phone numbers, email addresses, date of birth, gender, race, and ethnicity) must be managed to support unique patient identification, reporting, care provision requirements. Patient Demographic information may also include information about the patient's contacts, methods of contact (e.g., email or telephone), and modes of contact (e.g., call secretary during the day, send text message on the weekend). Patient demographic data are captured and maintained as discrete fields and may be enumerated, numeric, or codified according to scope of practice, organizational policy, and/or jurisdictional law. Key patient identifiers (i.e., name and primary patient record identifier) often appear on patient information output (e.g., rendering of a patient's record). Patients may have multiple, and/or compound names, sometimes employing accent marks or special characters. To help parse patient names, discete fields are often used. Example: For example, "Mary Jane Sue Smith" may be parsed as: First-name: “Mary Jane", Middle-name: ”Sue", Last-name: “Smith". Some jurisdictions may specify the capture and reporting of key patient demographic information (e.g., the "Meaningful Use, Stage 2" information requirements in the USA).

Criteria N:
CPS.1.2#01 SHALL

The system SHALL provide the ability to capture demographic information as discrete data as part of the patient record.

CPS.1.2#02 SHALL

The system SHALL provide the ability to maintain demographic information as discrete data as part of the patient record.

CPS.1.2#03 SHALL

The system SHALL provide the ability to render demographic information as discrete data as part of the patient record.

CPS.1.2#04 SHALL

The system SHALL provide the ability to manage historic information for demographic data including prior names, addresses, phone numbers and email addresses.

CPS.1.2#05 dependent SHALL

The system SHALL render a set of patient identifying information at each interaction with the patient record, according to scope of practice, organizational policy, and/or jurisdictional law (e.g., a certain realm may require that the patient's picture appear on every screen that is used during a provider's face-to-face interactions with the patient).

CPS.1.2#06 MAY

The system MAY store the demographic information (and other meaningful individual identifiers) separately from clinical data for identity protection purposes.

CPS.1.2#07 SHALL

The system SHALL provide the ability to capture valid date/time values in discrete fields ( e.g., 2011/12/31 2330), including valid incomplete or partial date/time values (e.g., 2011/12).

CPS.1.2#08 SHOULD

The system SHOULD provide the ability to enter a partial date/time if the exact date/time of birth or death is unknown (e.g., year/month only).

CPS.1.2#09 SHALL

The system SHALL provide the ability to capture the patient's gender used for administrative purposes (as distinct from the clinical gender).

CPS.1.2#10 SHOULD

The system SHOULD provide the ability to manage multiple active addresses for the patient.

CPS.1.2#11 SHOULD

The system SHOULD provide the ability to manage multiple active phone numbers for the patient.

CPS.1.2#12 SHOULD

The system SHOULD provide the ability to manage the names and contact information of the patient's personal representatives (e.g., guardian, surrogate or financial guarantor) and personal relationships (e.g., foster parents or biological parents).

CPS.1.2#13 dependent SHALL

The system SHALL provide the ability to manage the date/time of birth, down to the minute, according to scope of practice, organizational policy, and/or jurisdictional law.

CPS.1.2#14 SHOULD

The system SHOULD provide the ability to capture patient demographics through integration with hospital systems to facilitate patient registration.

CPS.1.2#15 SHOULD

The system SHOULD provide the ability for the patient to annotate demographic data.

CPS.1.2#16 SHOULD

The system SHOULD determine and render a patient's age and age units for any given date.

CPS.1.2#17 dependent MAY

The system MAY analyze and render potential merge matches for registrations according to organizational policy.

CPS.1.2#18 SHALL

The system SHALL provide the ability to manage multiple patient names in each name component field (e.g., first, middle, last, suffix, or title).

CPS.1.2#19 SHALL

The system SHALL provide the ability to manage patient names that include any accent marks or special characters.

CPS.1.2#20 MAY

The system MAY provide the ability to link family or group members so that information that is common to all the members can be updated.


Source

{
  "resourceType" : "Requirements",
  "id" : "EHRSFMR2.1-CPS.1.2",
  "meta" : {
    "profile" : [
      "http://hl7.org/ehrs/StructureDefinition/FMFunction"
    ]
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <span id=\"description\"><b>Statement <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b> <div><p>Manage patient demographic information.</p>\n</div></span>\n\n \n <span id=\"purpose\"><b>Description <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Informative Content\" class=\"informative-flag\">I</a>:</b> <div><p>Demographic information (including names, addresses, phone numbers, email addresses, date of birth, gender, race, and ethnicity) must be managed to support unique patient identification, reporting, care provision requirements. Patient Demographic information may also include information about the patient's contacts, methods of contact (e.g., email or telephone), and modes of contact (e.g., call secretary during the day, send text message on the weekend). Patient demographic data are captured and maintained as discrete fields and may be enumerated, numeric, or codified according to scope of practice, organizational policy, and/or jurisdictional law. Key patient identifiers (i.e., name and primary patient record identifier) often appear on patient information output (e.g., rendering of a patient's record). Patients may have multiple, and/or compound names, sometimes employing accent marks or special characters. To help parse patient names, discete fields are often used.\nExample:\nFor example, &quot;Mary Jane Sue Smith&quot; may be parsed as: First-name: “Mary Jane&quot;, Middle-name: ”Sue&quot;, Last-name: “Smith&quot;. Some jurisdictions may specify the capture and reporting of key patient demographic information (e.g., the &quot;Meaningful Use, Stage 2&quot; information requirements in the USA).</p>\n</div></span>\n \n\n \n\n \n <span id=\"requirements\"><b>Criteria <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b></span>\n \n <table id=\"statements\" class=\"grid dict\">\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#01</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to capture demographic information as discrete data as part of the patient record.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#02</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to maintain demographic information as discrete data as part of the patient record.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#03</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to render demographic information as discrete data as part of the patient record.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#04</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to manage historic information for demographic data including prior names, addresses, phone numbers and email addresses.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#05</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL render a set of patient identifying information at each interaction with the patient record, according to scope of practice, organizational policy, and/or jurisdictional law (e.g., a certain realm may require that the patient's picture appear on every screen that is used during a provider's face-to-face interactions with the patient).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#06</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>MAY</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system MAY store the demographic information (and other meaningful individual identifiers) separately from clinical data for identity protection purposes.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#07</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to capture valid date/time values in discrete fields ( e.g., 2011/12/31 2330), including valid incomplete or partial date/time values (e.g., 2011/12).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#08</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to enter a partial date/time if the exact date/time of birth or death is unknown (e.g., year/month only).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#09</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to capture the patient's gender used for administrative purposes (as distinct from the clinical gender).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#10</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to manage multiple active addresses for the patient.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#11</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to manage multiple active phone numbers for the patient.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#12</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to manage the names and contact information of the patient's personal representatives (e.g., guardian, surrogate or financial guarantor) and personal relationships (e.g., foster parents or biological parents).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#13</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to manage the date/time of birth, down to the minute, according to scope of practice, organizational policy, and/or jurisdictional law.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#14</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to capture patient demographics through integration with hospital systems to facilitate patient registration.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#15</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability for the patient to annotate demographic data.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#16</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD determine and render a patient's age and age units for any given date.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#17</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n \n <span>MAY</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system MAY analyze and render potential merge matches for registrations according to organizational policy.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#18</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to manage multiple patient names in each name component field (e.g., first, middle, last, suffix, or title).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#19</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to manage patient names that include any accent marks or special characters.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>CPS.1.2#20</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>MAY</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system MAY provide the ability to link family or group members so that information that is common to all the members can be updated.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n </table>\n</div>"
  },
  "url" : "http://hl7.org/ehrs/Requirements/EHRSFMR2.1-CPS.1.2",
  "version" : "2.1.0",
  "name" : "CPS_1_2_Manage_Patient_Demographics",
  "title" : "CPS.1.2 Manage Patient Demographics (Function)",
  "status" : "active",
  "date" : "2024-11-26T16:30:50+00:00",
  "publisher" : "EHR WG",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://www.hl7.org/Special/committees/ehr"
        }
      ]
    }
  ],
  "description" : "Manage patient demographic information.",
  "jurisdiction" : [
    {
      "coding" : [
        {
          "system" : "http://unstats.un.org/unsd/methods/m49/m49.htm",
          "code" : "001",
          "display" : "World"
        }
      ]
    }
  ],
  "purpose" : "Demographic information (including names, addresses, phone numbers, email addresses, date of birth, gender, race, and ethnicity) must be managed to support unique patient identification, reporting, care provision requirements. Patient Demographic information may also include information about the patient's contacts, methods of contact (e.g., email or telephone), and modes of contact (e.g., call secretary during the day, send text message on the weekend). Patient demographic data are captured and maintained as discrete fields and may be enumerated, numeric, or codified according to scope of practice, organizational policy, and/or jurisdictional law. Key patient identifiers (i.e., name and primary patient record identifier) often appear on patient information output (e.g., rendering of a patient's record). Patients may have multiple, and/or compound names, sometimes employing accent marks or special characters. To help parse patient names, discete fields are often used.\nExample:\nFor example, \"Mary Jane Sue Smith\" may be parsed as: First-name: “Mary Jane\", Middle-name: ”Sue\", Last-name: “Smith\". Some jurisdictions may specify the capture and reporting of key patient demographic information (e.g., the \"Meaningful Use, Stage 2\" information requirements in the USA).",
  "statement" : [
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-01",
      "label" : "CPS.1.2#01",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL provide the ability to capture demographic information as discrete data as part of the patient record.",
      "derivedFrom" : "EHR-S_FM_R1.1 DC.1.1.2#1"
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-02",
      "label" : "CPS.1.2#02",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL provide the ability to maintain demographic information as discrete data as part of the patient record.",
      "derivedFrom" : "EHR-S_FM_R1.1 DC.1.1.2#2"
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-03",
      "label" : "CPS.1.2#03",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL provide the ability to render demographic information as discrete data as part of the patient record.",
      "derivedFrom" : "EHR-S_FM_R1.1 DC.1.1.2#3"
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-04",
      "label" : "CPS.1.2#04",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL provide the ability to manage historic information for demographic data including prior names, addresses, phone numbers and email addresses.",
      "derivedFrom" : "EHR-S_FM_R1.1 DC.1.1.2#6"
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : true
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-05",
      "label" : "CPS.1.2#05",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL render a set of patient identifying information at each interaction with the patient record, according to scope of practice, organizational policy, and/or jurisdictional law (e.g., a certain realm may require that the patient's picture appear on every screen that is used during a provider's face-to-face interactions with the patient).",
      "derivedFrom" : "EHR-S_FM_R1.1 DC.1.1.2#7"
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-06",
      "label" : "CPS.1.2#06",
      "conformance" : [
        "MAY"
      ],
      "conditionality" : false,
      "requirement" : "The system MAY store the demographic information (and other meaningful individual identifiers) separately from clinical data for identity protection purposes.",
      "derivedFrom" : "EHR-S_FM_R1.1 DC.1.1.2#10"
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-07",
      "label" : "CPS.1.2#07",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL provide the ability to capture valid date/time values in discrete fields ( e.g., 2011/12/31 2330), including valid incomplete or partial date/time values (e.g., 2011/12)."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-08",
      "label" : "CPS.1.2#08",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The system SHOULD provide the ability to enter a partial date/time if the exact date/time of birth or death is unknown (e.g., year/month only)."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-09",
      "label" : "CPS.1.2#09",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL provide the ability to capture the patient's gender used for administrative purposes (as distinct from the clinical gender)."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-10",
      "label" : "CPS.1.2#10",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The system SHOULD provide the ability to manage multiple active addresses for the patient."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-11",
      "label" : "CPS.1.2#11",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The system SHOULD provide the ability to manage multiple active phone numbers for the patient."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-12",
      "label" : "CPS.1.2#12",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The system SHOULD provide the ability to manage the names and contact information of the patient's personal representatives (e.g., guardian, surrogate or financial guarantor) and personal relationships (e.g., foster parents or biological parents)."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : true
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-13",
      "label" : "CPS.1.2#13",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL provide the ability to manage the date/time of birth, down to the minute, according to scope of practice, organizational policy, and/or jurisdictional law."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-14",
      "label" : "CPS.1.2#14",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The system SHOULD provide the ability to capture patient demographics through integration with hospital systems to facilitate patient registration."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-15",
      "label" : "CPS.1.2#15",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The system SHOULD provide the ability for the patient to annotate demographic data."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-16",
      "label" : "CPS.1.2#16",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The system SHOULD determine and render a patient's age and age units for any given date."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : true
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-17",
      "label" : "CPS.1.2#17",
      "conformance" : [
        "MAY"
      ],
      "conditionality" : false,
      "requirement" : "The system MAY analyze and render potential merge matches for registrations according to organizational policy."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-18",
      "label" : "CPS.1.2#18",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL provide the ability to manage multiple patient names in each name component field (e.g., first, middle, last, suffix, or title)."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-19",
      "label" : "CPS.1.2#19",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL provide the ability to manage patient names that include any accent marks or special characters."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-CPS.1.2-20",
      "label" : "CPS.1.2#20",
      "conformance" : [
        "MAY"
      ],
      "conditionality" : false,
      "requirement" : "The system MAY provide the ability to link family or group members so that information that is common to all the members can be updated."
    }
  ]
}

XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.